第 1 条：了解 TypeScript 和 JavaScript 之间的关系

Item 1: Understand the Relationship Between TypeScript and JavaScript

如果如果你长期使用 TypeScript，你将不可避免地听到“TypeScript is a superset of JavaScript”或“TypeScript is a typed superset of JavaScript”这样的说法。但这到底是什么意思？TypeScript 和 JavaScript 之间的关系是什么？由于这些语言之间的联系如此紧密，因此深入了解它们之间的关系是很好地使用 TypeScript 的基础。

If you use TypeScript for long, you’ll inevitably hear the phrase “TypeScript is a superset of JavaScript” or “TypeScript is a typed superset of JavaScript.” But what does this mean, exactly? And what is the relationship between TypeScript and JavaScript? Since these languages are so closely linked, a strong understanding of how they relate to each is the foundation for using TypeScript well.

TypeScript 在语法意义上是 JavaScript 的超集：只要你的 JavaScript 程序没有任何语法错误，那么它也是一个 TypeScript 程序。TypeScript 的类型检查器很可能会标记您的代码的一些问题。但这是一个独立的问题。TypeScript 仍会解析您的代码并发出 JavaScript。（这是关系的另一个关键部分。我们将在第 3 项中对此进行更多探讨。）

TypeScript is a superset of JavaScript in a syntactic sense: so long as your JavaScript program doesn’t have any syntax errors then it is also a TypeScript program. It’s quite likely that TypeScript’s type checker will flag some issues with your code. But this is an independent problem. TypeScript will still parse your code and emit JavaScript. (This is another key part of the relationship. We’ll explore this more in Item 3.)

TypeScript 文件使用.ts（或.tsx）扩展名，而不是JavaScript 文件的.js（或.jsx ）扩展名。这并不意味着 TypeScript 是一种完全不同的语言！由于 TypeScript 是 JavaScript 的超集，因此.js文件中的代码已经是 TypeScript。将main.js重命名为main.ts不会改变这一点。

TypeScript files use a .ts (or .tsx) extension, rather than the .js (or .jsx) extension of a JavaScript file. This doesn’t mean that TypeScript is a completely different language! Since TypeScript is a superset of JavaScript, the code in your .js files is already TypeScript. Renaming main.js to main.ts doesn’t change that.

这如果您要将现有的 JavaScript 代码库迁移到 TypeScript，这将非常有用。这意味着您无需用另一种语言重写任何代码即可开始使用 TypeScript 并获得它提供的好处。这如果您选择用 Java 等语言重写 JavaScript，则情况并非如此。这种温和的迁移路径是 TypeScript 的最佳特性之一。第 8 章将对这个主题进行更多讨论。

This is enormously helpful if you’re migrating an existing JavaScript codebase to TypeScript. It means that you don’t have to rewrite any of your code in another language to start using TypeScript and get the benefits it provides. This would not be true if you chose to rewrite your JavaScript in a language like Java. This gentle migration path is one of the best features of TypeScript. There will be much more to say about this topic in Chapter 8.

所有 JavaScript 程序都是 TypeScript 程序，但反之则不然：存在不是 JavaScript 程序的 TypeScript 程序。这是因为 TypeScript 添加了额外的语法来指定类型。（它添加了一些其他语法，主要是出于历史原因。请参阅条目 53。）

All JavaScript programs are TypeScript programs, but the converse is not true: there are TypeScript programs which are not JavaScript programs. This is because TypeScript adds additional syntax for specifying types. (There are some other bits of syntax it adds, largely for historical reasons. See Item 53.)

例如，这是一个有效的 TypeScript 程序：

For instance, this is a valid TypeScript program:

function greet(who:string) {
  console.log('Hello', who);
}

function greet(who: string) {
  console.log('Hello', who);
}

但是当你通过一个node需要 JavaScript 的程序运行它时，你会得到一个错误：

But when you run this through a program like node that expects JavaScript, you’ll get an error:

函数问候（谁：字符串）{
                  ^

语法错误：意外的标记：

function greet(who: string) {
                  ^

SyntaxError: Unexpected token :

是: string特定于 TypeScript 的类型注释。一旦你使用了它，你就超越了普通的 JavaScript（见图1-1）。

The : string is a type annotation that is specific to TypeScript. Once you use one, you’ve gone beyond plain JavaScript (see Figure 1-1).

图 1-1。所有 JavaScript 都是 TypeScript，但并非所有 TypeScript 都是 JavaScript

这并不是说 TypeScript 不为纯 JavaScript 程序提供价值。确实如此！例如，这个 JavaScript 程序：

This is not to say that TypeScript doesn’t provide value for plain JavaScript programs. It does! For example, this JavaScript program:

let city = 'new york city';
console.log(city.toUppercase());

let city = 'new york city';
console.log(city.toUppercase());

运行时会报错：

will throw an error when you run it:

类型错误：city.toUppercase 不是函数

TypeError: city.toUppercase is not a function

该程序中没有类型注释，但 TypeScript 的类型检查器仍然能够发现问题：

There are no type annotations in this program, but TypeScript’s type checker is still able to spot the problem:

let city = 'new york city';
console.log(city.toUppercase());
              // ~~~~~~~~~~~ Property 'toUppercase' does not exist on type
              //             'string'. Did you mean 'toUpperCase'?

let city = 'new york city';
console.log(city.toUppercase());
              // ~~~~~~~~~~~ Property 'toUppercase' does not exist on type
              //             'string'. Did you mean 'toUpperCase'?

您不必告诉 TypeScript 的类型是city：string它是从初始值推断出来的。类型推断是 TypeScript 的关键部分，第 3 章探讨了如何很好地使用它。

You didn’t have to tell TypeScript that the type of city was string: it inferred it from the initial value. Type inference is a key part of TypeScript and Chapter 3 explores how to use it well.

TypeScript 类型系统的目标之一是检测将在运行时抛出异常的代码，而无需运行您的代码。当您听到 TypeScript 被描述为“静态”类型系统时，它指的就是这个。类型检查器不能总是发现会抛出异常的代码，但它会尝试。

One of the goals of TypeScript’s type system is to detect code that will throw an exception at runtime, without having to run your code. When you hear TypeScript described as a “static” type system, this is what it refers to. The type checker cannot always spot code that will throw exceptions, but it will try.

即使您的代码没有抛出异常，它仍然可能不会按照您的意图进行。TypeScript 也试图捕捉其中的一些问题。例如，这个 JavaScript程序：

Even if your code doesn’t throw an exception, it still might not do what you intend. TypeScript tries to catch some of these issues, too. For example, this JavaScript program:

const states = [
  {name: 'Alabama', capital: 'Montgomery'},
  {name: 'Alaska',  capital: 'Juneau'},
  {name: 'Arizona', capital: 'Phoenix'},
  // ...
];
for (const state of states) {
  console.log(state.capitol);
}

const states = [
  {name: 'Alabama', capital: 'Montgomery'},
  {name: 'Alaska',  capital: 'Juneau'},
  {name: 'Arizona', capital: 'Phoenix'},
  // ...
];
for (const state of states) {
  console.log(state.capitol);
}

将记录：

will log:

不明确的
不明确的
不明确的

undefined
undefined
undefined

哎呀！什么地方出了错？该程序是有效的 JavaScript（因此也是 TypeScript）。它运行时没有抛出任何错误。但它显然没有按照你的意图去做。即使不添加类型注释，TypeScript 的类型检查器也能够发现错误（并提供有用的建议）：

Whoops! What went wrong? This program is valid JavaScript (and hence TypeScript). And it ran without throwing any errors. But it clearly didn’t do what you intended. Even without adding type annotations, TypeScript’s type checker is able to spot the error (and offer a helpful suggestion):

for (const state of states) {
  console.log(state.capitol);
                 // ~~~~~~~ Property 'capitol' does not exist on type
                 //         '{ name: string; capital: string; }'.
                 //         Did you mean 'capital'?
}

for (const state of states) {
  console.log(state.capitol);
                 // ~~~~~~~ Property 'capitol' does not exist on type
                 //         '{ name: string; capital: string; }'.
                 //         Did you mean 'capital'?
}

虽然即使您不提供类型注释，TypeScript 也可以捕获错误，但如果您提供类型注释，它就能完成更彻底的工作。这是因为类型注释告诉 TypeScript 你的意图是什么，这让它可以发现代码行为与你的意图不匹配的地方。例如，如果您在前面的示例中扭转了capital/拼写错误怎么办？capitol

While TypeScript can catch errors even if you don’t provide type annotations, it’s able to do a much more thorough job if you do. This is because type annotations tell TypeScript what your intent is, and this lets it spot places where your code’s behavior does not match your intent. For example, what if you’d reversed the capital/capitol spelling mistake in the previous example?

const states = [
  {name: 'Alabama', capitol: 'Montgomery'},
  {name: 'Alaska',  capitol: 'Juneau'},
  {name: 'Arizona', capitol: 'Phoenix'},
  // ...
];
for (const state of states) {
  console.log(state.capital);
                 // ~~~~~~~ Property 'capital' does not exist on type
                 //         '{ name: string; capitol: string; }'.
                 //         Did you mean 'capitol'?
}

const states = [
  {name: 'Alabama', capitol: 'Montgomery'},
  {name: 'Alaska',  capitol: 'Juneau'},
  {name: 'Arizona', capitol: 'Phoenix'},
  // ...
];
for (const state of states) {
  console.log(state.capital);
                 // ~~~~~~~ Property 'capital' does not exist on type
                 //         '{ name: string; capitol: string; }'.
                 //         Did you mean 'capitol'?
}

之前非常有用的错误现在完全错了！问题是你用两种不同的方式拼写了同一个属性，而 TypeScript 不知道哪一个是正确的。它可以猜测，但不一定总是正确的。解决方案是通过明确声明以下类型来阐明您的意图states：

The error that was so helpful before now gets it exactly wrong! The problem is that you’ve spelled the same property two different ways, and TypeScript doesn’t know which one is right. It can guess, but it may not always be correct. The solution is to clarify your intent by explicitly declaring the type of states:

interface State {
  name: string;
  capital: string;
}
const states:State[] = [
  {name: 'Alabama', capitol: 'Montgomery'},
                 // ~~~~~~~~~~~~~~~~~~~~~
  {name: 'Alaska',  capitol: 'Juneau'},
                 // ~~~~~~~~~~~~~~~~~
  {name: 'Arizona', capitol: 'Phoenix'},
                 // ~~~~~~~~~~~~~~~~~~ Object literal may only specify known
                 //         properties, but 'capitol' does not exist in type
                 //         'State'.  Did you mean to write 'capital'?
  // ...
];
for (const state of states) {
  console.log(state.capital);
}

interface State {
  name: string;
  capital: string;
}
const states: State[] = [
  {name: 'Alabama', capitol: 'Montgomery'},
                 // ~~~~~~~~~~~~~~~~~~~~~
  {name: 'Alaska',  capitol: 'Juneau'},
                 // ~~~~~~~~~~~~~~~~~
  {name: 'Arizona', capitol: 'Phoenix'},
                 // ~~~~~~~~~~~~~~~~~~ Object literal may only specify known
                 //         properties, but 'capitol' does not exist in type
                 //         'State'.  Did you mean to write 'capital'?
  // ...
];
for (const state of states) {
  console.log(state.capital);
}

现在错误与问题匹配，建议的修复是正确的。通过阐明我们的意图，您还帮助 TypeScript 发现了其他潜在问题。例如，如果您capitol在数组中只拼错一次，那么之前就不会出现错误。但是对于类型注解，有：

Now the errors match the problem and the suggested fix is correct. By spelling out our intent, you’ve also helped TypeScript spot other potential problems. For instance, had you only misspelled capitol once in the array, there wouldn’t have been an error before. But with the type annotation, there is:

const states:State[] = [
  {name: 'Alabama', capital: 'Montgomery'},
  {name: 'Alaska',  capitol: 'Juneau'},
                 // ~~~~~~~~~~~~~~~~~ Did you mean to write 'capital'?
  {name: 'Arizona', capital: 'Phoenix'},
  // ...
];

const states: State[] = [
  {name: 'Alabama', capital: 'Montgomery'},
  {name: 'Alaska',  capitol: 'Juneau'},
                 // ~~~~~~~~~~~~~~~~~ Did you mean to write 'capital'?
  {name: 'Arizona', capital: 'Phoenix'},
  // ...
];

根据维恩图，我们可以添加一组新的程序：通过类型检查器的 TypeScript 程序（见图1-2）。

In terms of the Venn diagram, we can add in a new group of programs: TypeScript programs which pass the type checker (see Figure 1-2).

图 1-2。所有 JavaScript 程序都是 TypeScript 程序。但是只有一些 JavaScript（和 TypeScript）程序通过了类型检查器。

如果您觉得“TypeScript 是 JavaScript 的超集”这一说法有误，那可能是因为您正在考虑图中的第三组程序。实际上，这是与使用 TypeScript 的日常体验最相关的一个。通常，当您使用 TypeScript 时，您会尝试让您的代码通过所有类型检查。

If the statement that “TypeScript is a superset of JavaScript” feels wrong to you, it may be because you’re thinking of this third set of programs in the diagram. In practice, this is the most relevant one to the day-to-day experience of using TypeScript. Generally when you use TypeScript, you try to keep your code passing all the type checks.

TypeScript 的类型系统模拟了JavaScript 的运行时行为。如果您来自具有更严格的运行时检查的语言，这可能会导致一些意外。例如：

TypeScript’s type system models the runtime behavior of JavaScript. This may result in some surprises if you’re coming from a language with stricter runtime checks. For example:

const x = 2 + '3';  // OK, type is string
const y = '2' + 3;  // OK, type is string

const x = 2 + '3';  // OK, type is string
const y = '2' + 3;  // OK, type is string

这些语句都通过了类型检查器，即使它们是有问题的并且在许多其他语言中确实会产生运行时错误。但这确实模拟了 JavaScript 的运行时行为，其中两个表达式都会产生 string "23"。

These statements both pass the type checker, even though they are questionable and do produce runtime errors in many other languages. But this does model the runtime behavior of JavaScript, where both expressions result in the string "23".

不过，TypeScript 确实在某处画了线。类型检查器会标记所有这些语句中的问题，即使它们在运行时不会抛出异常：

TypeScript does draw the line somewhere, though. The type checker flags issues in all of these statements, even though they do not throw exceptions at runtime:

const a = null + 7;  // Evaluates to 7 in JS
       // ~~~~ Operator '+' cannot be applied to types ...
const b = [] + 12;  // Evaluates to '12' in JS
       // ~~~~~~~ Operator '+' cannot be applied to types ...
alert('Hello', 'TypeScript');  // alerts "Hello"
            // ~~~~~~~~~~~~ Expected 0-1 arguments, but got 2

const a = null + 7;  // Evaluates to 7 in JS
       // ~~~~ Operator '+' cannot be applied to types ...
const b = [] + 12;  // Evaluates to '12' in JS
       // ~~~~~~~ Operator '+' cannot be applied to types ...
alert('Hello', 'TypeScript');  // alerts "Hello"
            // ~~~~~~~~~~~~ Expected 0-1 arguments, but got 2

TypeScript 类型系统的指导原则是它应该模拟 JavaScript 的运行时行为。但在所有这些情况下，TypeScript 认为奇怪的用法更有可能是错误的结果，而不是开发人员的意图，因此它不仅仅是对运行时行为进行建模。capital我们在/ example中看到了另一个例子capitol，其中程序没有抛出（它记录了undefined）但类型检查器仍然标记了一个错误。

The guiding principle of TypeScript’s type system is that it should model JavaScript’s runtime behavior. But in all of these cases, TypeScript considers it more likely that the odd usage is the result of an error than the developer’s intent, so it goes beyond simply modeling the runtime behavior. We saw another example of this in the capital/capitol example, where the program didn’t throw (it logged undefined) but the type checker still flagged an error.

TypeScript 如何决定何时模拟 JavaScript 的运行时行为以及何时超越它？归根结底，这是一个品味问题。通过采用 TypeScript，你相信构建它的团队的判断。如果您喜欢添加nulland7或[]and 12，或者使用多余的参数调用函数，那么 TypeScript 可能不适合您！

How does TypeScript decide when to model JavaScript’s runtime behavior and when to go beyond it? Ultimately this is a matter of taste. By adopting TypeScript you’re trusting the judgment of the team that builds it. If you enjoy adding null and 7 or [] and 12, or calling functions with superfluous arguments, then TypeScript might not be for you!

如果您的程序进行了类型检查，它还会在运行时抛出错误吗？答案是“是的”。这是一个例子：

If your program type checks, could it still throw an error at runtime? The answer is “yes.” Here’s an example:

const names = ['Alice', 'Bob'];
console.log(names[2].toUpperCase());

const names = ['Alice', 'Bob'];
console.log(names[2].toUpperCase());

当你运行它时，它会抛出：

When you run this, it throws:

类型错误：无法读取未定义的属性“toUpperCase”

TypeError: Cannot read property 'toUpperCase' of undefined

TypeScript 假定数组访问在范围内，但事实并非如此。结果是一个例外。

TypeScript assumed the array access would be within bounds, but it was not. The result was an exception.

当您使用该类型时，也经常会出现未捕获的错误any，我们将在第 5 项中讨论，并在第 5 章中更详细地讨论。

Uncaught errors also frequently come up when you use the any type, which we’ll discuss in Item 5 and in more detail in Chapter 5.

这些异常的根本原因是 TypeScript 对值的类型和现实的理解发生了分歧。可以保证其静态类型的准确性的类型系统被认为是可靠的。TypeScript 的类型系统非常不健全，也从未打算如此。如果健全性对你很重要，你可能想看看其他语言，比如 Reason 或 Elm。虽然这些确实提供了更多的运行时安全保证，但这是有代价的：两者都不是 JavaScript 的超集，因此迁移会更加复杂。

The root cause of these exceptions is that TypeScript’s understanding of a value’s type and reality have diverged. A type system which can guarantee the accuracy of its static types is said to be sound. TypeScript’s type system is very much not sound, nor was it ever intended to be. If soundness is important to you, you may want to look at other languages like Reason or Elm. While these do offer more guarantees of runtime safety, this comes at a cost: neither is a superset of JavaScript, so migration will be more complicated.

第 2 项：了解您使用的 TypeScript 选项

Item 2: Know Which TypeScript Options You’re Using

做这段代码通过了类型检查器？

Does this code pass the type checker?

function add(a, b) {
  return a + b;
}
add(10, null);

function add(a, b) {
  return a + b;
}
add(10, null);

在不知道您使用的是哪个选项的情况下，这是不可能的！TypeScript 编译器有大量这样的集合，在撰写本文时将近 100 个。

Without knowing which options you’re using, it’s impossible to say! The TypeScript compiler has an enormous set of these, nearly 100 at the time of this writing.

它们可以通过命令行设置：

They can be set via the command line:

$ tsc --noImplicitAny 程序.ts

$ tsc --noImplicitAny program.ts

或者通过配置文件tsconfig.json：

or via a configuration file, tsconfig.json:

{
  "compilerOptions": {
    "noImplicitAny": true
  }
}

{
  "compilerOptions": {
    "noImplicitAny": true
  }
}

您应该更喜欢配置文件。它确保你的同事和工具都知道你打算如何使用 TypeScript。您可以通过运行创建一个tsc --init。

You should prefer the configuration file. It ensures that your coworkers and tools all know exactly how you plan to use TypeScript. You can create one by running tsc --init.

许多 TypeScript 的配置设置控制它在何处查找源文件以及它生成的输出类型。但是一些控制语言本身的核心方面。这些是大多数语言不会留给用户的高级设计选择。根据配置方式的不同，TypeScript 感觉就像是一种非常不同的语言。要有效地使用它，您应该了解这些设置中最重要的部分：noImplicitAny和strictNullChecks。

Many of TypeScript’s configuration settings control where it looks for source files and what sort of output it generates. But a few control core aspects of the language itself. These are high-level design choices that most languages do not leave to their users. TypeScript can feel like a very different language depending on how it is configured. To use it effectively, you should understand the most important of these settings: noImplicitAny and strictNullChecks.

noImplicitAny控制变量是否必须具有已知类型。noImplicitAny此代码在关闭时有效：

noImplicitAny controls whether variables must have known types. This code is valid when noImplicitAny is off:

function add(a, b) {
  return a + b;
}

function add(a, b) {
  return a + b;
}

如果您将鼠标悬停add在编辑器中的符号上，它将显示 TypeScript 对该函数类型的推断：

If you mouse over the add symbol in your editor, it will reveal what TypeScript has inferred about the type of that function:

函数添加（a：任何，b：任何）：任何

function add(a: any, b: any): any

这些any类型有效地禁用了涉及这些参数的代码的类型检查器。any是一个有用的工具，但应谨慎使用。有关更多信息any，请参阅第 5 项和第 3 章。

The any types effectively disable the type checker for code involving these parameters. any is a useful tool, but it should be used with caution. For much more on any, see Item 5 and Chapter 3.

这些被称为implicitany是因为你从来没有写过“any”这个词，但仍然会遇到危险的any类型。如果您设置选项，这将成为一个错误noImplicitAny：

These are called implicit anys because you never wrote the word “any” but still wound up with dangerous any types. This becomes an error if you set the noImplicitAny option:

function add(a, b) {
          // ~    Parameter 'a' implicitly has an 'any' type
          //    ~ Parameter 'b' implicitly has an 'any' type
  return a + b;
}

function add(a, b) {
          // ~    Parameter 'a' implicitly has an 'any' type
          //    ~ Parameter 'b' implicitly has an 'any' type
  return a + b;
}

这些错误可以通过显式编写类型声明来修复，或者: any是更具体的类型：

These errors can be fixed by explicitly writing type declarations, either : any or a more specific type:

function add(a: number, b:number) {
  return a + b;
}

function add(a: number, b: number) {
  return a + b;
}

noImplicitAny当 TypeScript 有类型信息时，它是最有用的，所以你应该确保尽可能设置。一旦您习惯了所有具有类型的变量，没有类型的 TypeScriptnoImplicitAny感觉就像是一种不同的语言。

TypeScript is the most helpful when it has type information, so you should be sure to set noImplicitAny whenever possible. Once you grow accustomed to all variables having types, TypeScript without noImplicitAny feels almost like a different language.

对于新项目，您应该从 on 开始noImplicitAny，以便在编写代码时编写类型。这将有助于 TypeScript 发现问题，提高代码的可读性，并增强您的开发体验（参见条款 6）。noImplicitAny仅当您将项目从 JavaScript 转换为 TypeScript 时才适合离开（请参阅第8 章）。

For new projects, you should start with noImplicitAny on, so that you write the types as you write your code. This will help TypeScript spot problems, improve the readability of your code, and enhance your development experience (see Item 6). Leaving noImplicitAny off is only appropriate if you’re transitioning a project from JavaScript to TypeScript (see Chapter 8).

strictNullChecks控制 和 是否null是undefined每种类型中的允许值。

strictNullChecks controls whether null and undefined are permissible values in every type.

strictNullChecks此代码在关闭时有效：

This code is valid when strictNullChecks is off:

const x:number = null;  // OK, null is a valid number

const x: number = null;  // OK, null is a valid number

但是当你打开时会触发错误strictNullChecks：

but triggers an error when you turn strictNullChecks on:

const x:number = null;
//    ~ Type 'null' is not assignable to type 'number'

const x: number = null;
//    ~ Type 'null' is not assignable to type 'number'

undefined如果您使用而不是，也会发生类似的错误null。

A similar error would have occurred had you used undefined instead of null.

如果你的意思是 allow null，你可以通过明确你的意图来修复错误：

If you mean to allow null, you can fix the error by making your intent explicit:

const x:number | null = null;

const x: number | null = null;

如果您不想允许null，则需要追踪它的来源并添加检查或断言：

If you do not wish to permit null, you’ll need to track down where it came from and add either a check or an assertion:

   const el = document.getElementById('status');
   el.textContent = 'Ready';
// ~~ Object is possibly 'null'

   if (el) {
     el.textContent = 'Ready';  // OK, null has been excluded
   }
   el!.textContent = 'Ready';  // OK, we've asserted that el is non-null

   const el = document.getElementById('status');
   el.textContent = 'Ready';
// ~~ Object is possibly 'null'

   if (el) {
     el.textContent = 'Ready';  // OK, null has been excluded
   }
   el!.textContent = 'Ready';  // OK, we've asserted that el is non-null

strictNullChecksnull对于捕获涉及和值的错误非常有帮助undefined，但它确实增加了使用该语言的难度。如果您要开始一个新项目，请尝试设置strictNullChecks. 但是，如果您是该语言的新手或正在迁移 JavaScript 代码库，您可能会选择将其关闭。你当然应该noImplicitAny先设置再设置strictNullChecks。

strictNullChecks is tremendously helpful for catching errors involving null and undefined values, but it does increase the difficulty of using the language. If you’re starting a new project, try setting strictNullChecks. But if you’re new to the language or migrating a JavaScript codebase, you may elect to leave it off. You should certainly set noImplicitAny before you set strictNullChecks.

如果您选择不使用strictNullChecks，请留意可怕的“undefined is not an object”运行时错误。其中每一项都提醒您应该考虑启用更严格的检查。随着项目的增长，更改此设置只会变得更加困难，因此在启用它之前尽量不要等待太久。

If you choose to work without strictNullChecks, keep an eye out for the dreaded “undefined is not an object” runtime error. Every one of these is a reminder that you should consider enabling stricter checking. Changing this setting will only get harder as your project grows, so try not to wait too long before enabling it.

那里还有许多影响语言语义的其他设置（例如，noImplicitThis和strictFunctionTypes），但与noImplicitAny和相比，这些都是次要的strictNullChecks。要启用所有这些检查，请打开strict设置。TypeScript 能够捕获最多的错误strict，所以这就是你最终想要结束的地方。

There are many other settings that affect language semantics (e.g., noImplicitThis and strictFunctionTypes), but these are minor compared to noImplicitAny and strictNullChecks. To enable all of these checks, turn on the strict setting. TypeScript is able to catch the most errors with strict, so this is where you eventually want to wind up.

知道您正在使用哪些选项！如果同事分享了一个 TypeScript 示例，而您无法重现他们的错误，请确保您的编译器选项相同。

Know which options you’re using! If a coworker shares a TypeScript example and you’re unable to reproduce their errors, make sure your compiler options are the same.

第 3 条：了解代码生成与类型无关

Item 3: Understand That Code Generation Is Independent of Types

在高层tsc（TypeScript 编译器）做两件事：

At a high level, tsc (the TypeScript compiler) does two things:

• 它将下一代 TypeScript/JavaScript 转换为可在浏览器中运行的旧版 JavaScript（“转译”）。

• It converts next-generation TypeScript/JavaScript to an older version of JavaScript that works in browsers (“transpiling”).

• 它会检查您的代码是否存在类型错误。

• It checks your code for type errors.

令人惊讶的是，这两种行为完全相互独立。换句话说，代码中的类型不会影响 TypeScript 发出的 JavaScript。由于执行的是这个 JavaScript，这意味着您的类型不会影响代码的运行方式。

What’s surprising is that these two behaviors are entirely independent of one another. Put another way, the types in your code cannot affect the JavaScript that TypeScript emits. Since it’s this JavaScript that gets executed, this means that your types can’t affect the way your code runs.

这有一些令人惊讶的含义，并且应该告诉您关于 TypeScript 能为您做什么和不能为您做什么的期望。

This has some surprising implications and should inform your expectations about what TypeScript can and cannot do for you.

$猫测试.ts
让 x = '你好';
x = 1234；
$ tsc 测试.ts
test.ts:2:1 - 错误 TS2322：类型“1234”不可分配给类型“string”

2 x = 1234；
  ~

$猫测试.js
var x = '你好';
x = 1234；

$ cat test.ts
let x = 'hello';
x = 1234;
$ tsc test.ts
test.ts:2:1 - error TS2322: Type '1234' is not assignable to type 'string'

2 x = 1234;
  ~

$ cat test.js
var x = 'hello';
x = 1234;

interface Square {
  width: number;
}
interface Rectangle extends Square {
  height:number;
}
type Shape = Square | Rectangle;

function calculateArea(shape:Shape) {
  if (shape instanceof Rectangle) {
                    // ~~~~~~~~~ 'Rectangle' only refers to a type,
                    //           but is being used as a value here
    return shape.width * shape.height;
                    //         ~~~~~~ Property 'height' does not exist
                    //                on type 'Shape'
  } else {
    return shape.width * shape.width;
  }
}

interface Square {
  width: number;
}
interface Rectangle extends Square {
  height: number;
}
type Shape = Square | Rectangle;

function calculateArea(shape: Shape) {
  if (shape instanceof Rectangle) {
                    // ~~~~~~~~~ 'Rectangle' only refers to a type,
                    //           but is being used as a value here
    return shape.width * shape.height;
                    //         ~~~~~~ Property 'height' does not exist
                    //                on type 'Shape'
  } else {
    return shape.width * shape.width;
  }
}

function calculateArea(shape:Shape) {
  if ('height' in shape) {
    shape;  // Type is Rectangle
    return shape.width * shape.height;
  } else {
    shape;  // Type is Square
    return shape.width * shape.width;
  }
}

function calculateArea(shape: Shape) {
  if ('height' in shape) {
    shape;  // Type is Rectangle
    return shape.width * shape.height;
  } else {
    shape;  // Type is Square
    return shape.width * shape.width;
  }
}

interface Square {
  kind: 'square';
  width: number;
}
interface Rectangle {
  kind: 'rectangle';
  height: number;
  width:number;
}
type Shape = Square | Rectangle;

function calculateArea(shape:Shape) {
  if (shape.kind === 'rectangle') {
    shape;  // Type is Rectangle
    return shape.width * shape.height;
  } else {
    shape;  // Type is Square
    return shape.width * shape.width;
  }
}

interface Square {
  kind: 'square';
  width: number;
}
interface Rectangle {
  kind: 'rectangle';
  height: number;
  width: number;
}
type Shape = Square | Rectangle;

function calculateArea(shape: Shape) {
  if (shape.kind === 'rectangle') {
    shape;  // Type is Rectangle
    return shape.width * shape.height;
  } else {
    shape;  // Type is Square
    return shape.width * shape.width;
  }
}

class Square {
  constructor(public width: number) {}
}
class Rectangle extends Square {
  constructor(public width: number, public height:number) {
    super(width);
  }
}
type Shape = Square | Rectangle;

function calculateArea(shape:Shape) {
  if (shape instanceof Rectangle) {
    shape;  // Type is Rectangle
    return shape.width * shape.height;
  } else {
    shape;  // Type is Square
    return shape.width * shape.width;  // OK
  }
}

class Square {
  constructor(public width: number) {}
}
class Rectangle extends Square {
  constructor(public width: number, public height: number) {
    super(width);
  }
}
type Shape = Square | Rectangle;

function calculateArea(shape: Shape) {
  if (shape instanceof Rectangle) {
    shape;  // Type is Rectangle
    return shape.width * shape.height;
  } else {
    shape;  // Type is Square
    return shape.width * shape.width;  // OK
  }
}

function asNumber(val:number | string): number {
  return val as number;
}

function asNumber(val: number | string): number {
  return val as number;
}

function asNumber(val) {
  return val;
}

function asNumber(val) {
  return val;
}

function asNumber(val:number | string): number {
  return typeof(val) === 'string' ? Number(val) : val;
}

function asNumber(val: number | string): number {
  return typeof(val) === 'string' ? Number(val) : val;
}

function setLightSwitch(value:boolean) {
  switch (value) {
    case true:
      turnLightOn();
      break;
    case false:
      turnLightOff();
      break;
    default:
      console.log(`I'm afraid I can't do that.`);
  }
}

function setLightSwitch(value: boolean) {
  switch (value) {
    case true:
      turnLightOn();
      break;
    case false:
      turnLightOff();
      break;
    default:
      console.log(`I'm afraid I can't do that.`);
  }
}

interface LightApiResponse {
  lightSwitchValue: boolean;
}
async function setLight() {
  const response = await fetch('/light');
  const result:LightApiResponse = await response.json();
  setLightSwitch(result.lightSwitchValue);
}

interface LightApiResponse {
  lightSwitchValue: boolean;
}
async function setLight() {
  const response = await fetch('/light');
  const result: LightApiResponse = await response.json();
  setLightSwitch(result.lightSwitchValue);
}

function add(a：：：：number, b_ number) { return a + b; }
      // ~~~ Duplicate function implementation
function add(a_ string, b_string) { return a + b; }
      // ~~~ Duplicate function implementation

function add(a: number, b: number) { return a + b; }
      // ~~~ Duplicate function implementation
function add(a: string, b: string) { return a + b; }
      // ~~~ Duplicate function implementation

function add(a：：：：number, b_ number): number;
function add(a_ string, b_string): string;

function add(a, b) {
  return a + b;
}

const three = add(1, 2);  // Type is number
const twelve = add('1', '2');  // Type is string

function add(a: number, b: number): number;
function add(a: string, b: string): string;

function add(a, b) {
  return a + b;
}

const three = add(1, 2);  // Type is number
const twelve = add('1', '2');  // Type is string

第 4 项：熟悉结构化类型

Item 4: Get Comfortable with Structural Typing

JavaScript本质上是鸭子类型的：如果您向函数传递一个具有所有正确属性的值，它不会关心您如何获得该值。它只会使用它。（“If it walks like a duck and talks like a duck...”）TypeScript 对这种行为进行建模，它有时会导致令人惊讶的结果，因为类型检查器对类型的理解可能比你想象的更广泛。很好地掌握结构类型将帮助您理解错误和非错误，并帮助您编写更健壮的代码。

JavaScript is inherently duck typed: if you pass a function a value with all the right properties, it won’t care how you made the value. It will just use it. (“If it walks like a duck and talks like a duck…”) TypeScript models this behavior, and it can sometimes lead to surprising results because the type checker’s understanding of a type may be broader than what you had in mind. Having a good grasp of structural typing will help you make sense of errors and non-errors and help you write more robust code.

假设您正在处理一个物理库并且有一个 2D 矢量类型：

Say you’re working on a physics library and have a 2D vector type:

interface Vector2D {
  x: number;
  y:number;
}

interface Vector2D {
  x: number;
  y: number;
}

你写了一个函数来计算它的长度：

You write a function to calculate its length:

function calculateLength(v:Vector2D) {
  return Math.sqrt(v.x * v.x + v.y * v.y);
}

function calculateLength(v: Vector2D) {
  return Math.sqrt(v.x * v.x + v.y * v.y);
}

现在介绍命名向量的概念：

Now you introduce the notion of a named vector:

interface NamedVector {
  name: string;
  x: number;
  y:number;
}

interface NamedVector {
  name: string;
  x: number;
  y: number;
}

该calculateLength函数将与NamedVectors 一起使用，因为它们具有x和y属性，即numbers。TypeScript 足够聪明，可以解决这个问题：

The calculateLength function will work with NamedVectors because they have x and y properties, which are numbers. TypeScript is smart enough to figure this out:

const v: NamedVector = { x: 3, y:4, name: 'Zee' };
calculateLength(v);  // OK, result is 5

const v: NamedVector = { x: 3, y: 4, name: 'Zee' };
calculateLength(v);  // OK, result is 5

Vector2D有趣的是，您从未声明和之间的关系NamedVector。而且您不必calculateLength为 s 编写 calculateLength的替代实现NamedVector。TypeScript 的类型系统正在模拟 JavaScript 的运行时行为（第 1 项）。它允许calculateLength用 a 调用，NamedVector因为它的结构与 兼容Vector2D。这就是术语“结构类型”的来源。

What is interesting is that you never declared the relationship between Vector2D and NamedVector. And you did not have to write an alternative implementation of calculateLength calculateLength for NamedVectors. TypeScript’s type system is modeling JavaScript’s runtime behavior (Item 1). It allowed calculateLength to be called with a NamedVector because its structure was compatible with Vector2D. This is where the term “structural typing” comes from.

但这也可能导致麻烦。假设您添加了一个 3D 矢量类型：

But this can also lead to trouble. Say you add a 3D vector type:

interface Vector3D {
  x: number;
  y: number;
  z:number;
}

interface Vector3D {
  x: number;
  y: number;
  z: number;
}

并编写一个函数来规范化它们（使它们的长度为 1）：

and write a function to normalize them (make their length 1):

function normalize(v：：：：Vector3D) {
  const length = calculateLength(v);
  return {
    x_ v.x / length,
    y_ v.y / length,
    z_v.z / length,
  };
}

function normalize(v: Vector3D) {
  const length = calculateLength(v);
  return {
    x: v.x / length,
    y: v.y / length,
    z: v.z / length,
  };
}

如果你调用这个函数，你可能会得到比单位长度更长的东西：

If you call this function, you’re likely to get something longer than unit length:

>归一化（{x: 3, y: 4, z: 5}） 
{ x: 0.6, y: 0.8, z: 1}

> normalize({x: 3, y: 4, z: 5})
{ x: 0.6, y: 0.8, z: 1 }

那么到底出了什么问题，为什么 TypeScript 没有捕捉到错误呢？

So what went wrong and why didn’t TypeScript catch the error?

错误是calculateLength在 2D 向量上运行但normalize在 3D 向量上运行。所以z组件在规范化中被忽略。

The bug is that calculateLength operates on 2D vectors but normalize operates on 3D vectors. So the z component is ignored in the normalization.

也许更令人惊讶的是类型检查器没有发现这个问题。为什么允许calculateLength使用 3D 向量调用，尽管它的类型声明说它采用 2D 向量？

What’s perhaps more surprising is that the type checker does not catch this issue. Why are you allowed to call calculateLength with a 3D vector, despite its type declaration saying that it takes 2D vectors?

对命名向量如此有效的做法在这里适得其反。calculateLength使用对象调用{x, y, z}不会引发错误。所以类型检查器也没有抱怨，而且这种行为导致了错误。（如果你希望这是一个错误，你有一些选择。我们将在条款 37中返回到这个例子。）

What worked so well with named vectors has backfired here. Calling calculateLength with an {x, y, z} object doesn’t throw an error. So the type checker doesn’t complain, either, and this behavior has led to a bug. (If you want this to be an error, you have some options. We’ll return to this example in Item 37.)

当您编写函数时，很容易想象它们将使用具有您声明的属性的参数调用，而没有其他属性。这被称为“密封”或“精确”类型，它不能在 TypeScript 的类型系统中表达。不管喜欢与否，您的类型是“开放的”。

As you write functions, it’s easy to imagine that they will be called with arguments having the properties you’ve declared and no others. This is known as a “sealed” or “precise” type, and it cannot be expressed in TypeScript’s type system. Like it or not, your types are “open.”

这有时会导致意外：

This can sometimes lead to surprises:

function calculateLengthL1(v:Vector3D) {
  let length = 0;
  for (const axis of Object.keys(v)) {
    const coord = v[axis];
               // ~~~~~~~ Element implicitly has an 'any' type because ...
               //         'string' can't be used to index type 'Vector3D'
    length += Math.abs(coord);
  }
  return length;
}

function calculateLengthL1(v: Vector3D) {
  let length = 0;
  for (const axis of Object.keys(v)) {
    const coord = v[axis];
               // ~~~~~~~ Element implicitly has an 'any' type because ...
               //         'string' can't be used to index type 'Vector3D'
    length += Math.abs(coord);
  }
  return length;
}

为什么这是一个错误？由于axis是 的键之一v，它是Vector3D，它应该是"x"、"y"或"z"。而且根据 的声明Vector3D，这些都是numbers，那么 的类型不应该coord是吗number？

Why is this an error? Since axis is one of the keys of v, which is a Vector3D, it should be either "x", "y", or "z". And according to the declaration of Vector3D, these are all numbers, so shouldn’t the type of coord be number?

这个错误是误报吗？不！TypeScript 抱怨是正确的。上一段中的逻辑假定 是Vector3D密封的并且没有其他属性。但它可以：

Is this error a false positive? No! TypeScript is correct to complain. The logic in the previous paragraph assumes that Vector3D is sealed and does not have other properties. But it could:

const vec3D = {x: 3, y: 4, z:1, address: '123 Broadway'};
calculateLengthL1(vec3D);  // OK, returns NaN

const vec3D = {x: 3, y: 4, z: 1, address: '123 Broadway'};
calculateLengthL1(vec3D);  // OK, returns NaN

由于v可以想象具有任何属性，因此类型axis是string. TypeScript 没有理由相信这v[axis]是一个数字，因为正如您刚才看到的，它可能不是。遍历对象可能很难正确输入。我们将在条款 54中回到这个主题，但在这种情况下，没有循环的实现会更好：

Since v could conceivably have any properties, the type of axis is string. TypeScript has no reason to believe that v[axis] is a number because, as you just saw, it might not be. Iterating over objects can be tricky to type correctly. We’ll return to this topic in Item 54, but in this case an implementation without loops would be better:

function calculateLengthL1(v:Vector3D) {
  return Math.abs(v.x) + Math.abs(v.y) + Math.abs(v.z);
}

function calculateLengthL1(v: Vector3D) {
  return Math.abs(v.x) + Math.abs(v.y) + Math.abs(v.z);
}

结构类型也可能导致classes 的意外，它们在结构上比较可分配性：

Structural typing can also lead to surprises with classes, which are compared structurally for assignability:

class C {
  foo: string;
  constructor(foo:string) {
    this.foo = foo;
  }
}

const c = new C('instance of C');
const d:C = { foo: 'object literal' };  // OK!

class C {
  foo: string;
  constructor(foo: string) {
    this.foo = foo;
  }
}

const c = new C('instance of C');
const d: C = { foo: 'object literal' };  // OK!

为什么可以d分配给C？它有一个foo属性是string. 此外，它还有一个constructor(from Object.prototype) 可以用一个参数调用（尽管它通常用零调用）。所以结构匹配。这C如果您在的构造函数中有逻辑并编写一个假设它正在运行的函数，则可能会导致意外。这与 C++ 或 Java 等语言完全不同，其中声明类型的参数C保证它将是C它的一个或一个子类。

Why is d assignable to C? It has a foo property that is a string. In addition, it has a constructor (from Object.prototype) that can be called with one argument (though it is usually called with zero). So the structures match. This might lead to surprises if you have logic in C’s constructor and write a function that assumes it’s run. This is quite different from languages like C++ or Java, where declaring a parameter of type C guarantees that it will be either C or a subclass of it.

当您编写测试时，结构类型非常有用。假设您有一个对数据库运行查询并处理结果的函数：

Structural typing is beneficial when you’re writing tests. Say you have a function that runs a query on a database and processes the results:

interface Author {
  first：：：：：：string;
  last_ string;
}
function getAuthors(database_ PostgresDB): Author[] {
  const authorRows = database.runQuery(`SELECT FIRST, LAST FROM AUTHORS`);
  return authorRows.map(row => ({first_ row[0], last_row[1]}));
}

interface Author {
  first: string;
  last: string;
}
function getAuthors(database: PostgresDB): Author[] {
  const authorRows = database.runQuery(`SELECT FIRST, LAST FROM AUTHORS`);
  return authorRows.map(row => ({first: row[0], last: row[1]}));
}

要对此进行测试，您可以创建一个模拟PostgresDB. 但更好的方法是使用结构类型并定义更窄的接口：

To test this, you could create a mock PostgresDB. But a better approach is to use structural typing and define a narrower interface:

interface DB {
  runQuery: (sql：：：：string) => any[];
}
function getAuthors(database_ DB): Author[] {
  const authorRows = database.runQuery(`SELECT FIRST, LAST FROM AUTHORS`);
  return authorRows.map(row => ({first_ row[0], last_row[1]}));
}

interface DB {
  runQuery: (sql: string) => any[];
}
function getAuthors(database: DB): Author[] {
  const authorRows = database.runQuery(`SELECT FIRST, LAST FROM AUTHORS`);
  return authorRows.map(row => ({first: row[0], last: row[1]}));
}

你仍然可以在生产中通过getAuthorsaPostgresDB因为它有一个runQuery方法。由于结构类型，PostgresDB不需要说它实现了DB. TypeScript 会发现它确实如此。

You can still pass getAuthors a PostgresDB in production since it has a runQuery method. Because of structural typing, the PostgresDB doesn’t need to say that it implements DB. TypeScript will figure out that it does.

当您编写测试时，您可以传入一个更简单的对象：

When you write your tests, you can pass in a simpler object instead:

test('getAuthors', () => {
  const authors = getAuthors({
    runQuery(sql:string) {
      return [['Toni', 'Morrison'], ['Maya', 'Angelou']];
    }
  });
  expect(authors).toEqual([
    {first: 'Toni', last: 'Morrison'},
    {first: 'Maya', last: 'Angelou'}
  ]);
});

test('getAuthors', () => {
  const authors = getAuthors({
    runQuery(sql: string) {
      return [['Toni', 'Morrison'], ['Maya', 'Angelou']];
    }
  });
  expect(authors).toEqual([
    {first: 'Toni', last: 'Morrison'},
    {first: 'Maya', last: 'Angelou'}
  ]);
});

TypeScript 将验证我们的测试DB是否符合接口。而且您的测试不需要了解有关您的生产数据库的任何信息：不需要模拟库！通过引入抽象 ( DB)，我们将逻辑（和测试）从特定实现 ( PostgresDB) 的细节中解放出来。

TypeScript will verify that our test DB conforms to the interface. And your tests don’t need to know anything about your production database: no mocking libraries necessary! By introducing an abstraction (DB), we’ve freed our logic (and tests) from the details of a specific implementation (PostgresDB).

结构类型的另一个优点是它可以干净利落地切断库之间的依赖关系。有关更多信息，请参阅条目 51。

Another advantage of structural typing is that it can cleanly sever dependencies between libraries. For more on this, see Item 51.

第 5 项：限制使用 any 类型

Item 5: Limit Use of the any Type

TypeScript 的类型系统是渐进的和可选的：渐进是因为你可以一点一点地向你的代码添加类型，可选是因为你可以随时禁用类型检查器。这些特性的关键是any类型：

TypeScript’s type system is gradual and optional: gradual because you can add types to your code bit by bit and optional because you can disable the type checker whenever you like. The key to these features is the any type:

   let age:number;
   age = '12';
// ~~~ Type '"12"' is not assignable to type 'number'
   age = '12' as any;  // OK

   let age: number;
   age = '12';
// ~~~ Type '"12"' is not assignable to type 'number'
   age = '12' as any;  // OK

类型检查器在这里抱怨是对的，但你可以通过输入as any. 当您开始使用 TypeScript 时，很容易使用any类型和type assertions ( as any) 当你不理解一个错误时，认为类型检查器不正确，或者只是不想花时间写出类型声明。在某些情况下，这可能没问题，但请注意，这any会消除使用 TypeScript 的许多优势。在使用它之前，您至少应该了解它的危险。

The type checker is right to complain here, but you can silence it just by typing as any. As you start using TypeScript, it’s tempting to use any types and type assertions (as any) when you don’t understand an error, think the type checker is incorrect, or simply don’t want to take the time to write out type declarations. In some cases this may be OK, but be aware that any eliminates many of the advantages of using TypeScript. You should at least understand its dangers before you use it.

age += 1;  // OK; at runtime, age is now "121"

age += 1;  // OK; at runtime, age is now "121"

function calculateAge(birthDate:Date): number {
  // ...
}

let birthDate:any = '1990-01-19';
calculateAge(birthDate);  // OK

function calculateAge(birthDate: Date): number {
  // ...
}

let birthDate: any = '1990-01-19';
calculateAge(birthDate);  // OK

没有任何类型的语言服务

There Are No Language Services for any Types

什么时候符号有类型，TypeScript 语言服务能够提供智能自动完成和上下文文档（如图1-3所示）。

When a symbol has a type, the TypeScript language services are able to provide intelligent autocomplete and contextual documentation (as shown in Figure 1-3).

图 1-3。TypeScript 语言服务能够为具有类型的符号提供上下文自动完成功能。

但对于具有any类型的符号，你就得靠自己了（图 1-4）。

but for symbols with an any type, you’re on your own (Figure 1-4).

图 1-4。任何类型的符号的属性都没有自动完成功能。

重命名是另一种此类服务。如果你有一个 Person 类型和函数来格式化一个人的名字：

Renaming is another such service. If you have a Person type and functions to format a person’s name:

interface Person {
  first: string;
  last:string;
}

const formatName = (p: Person) => `${p.first} ${p.last}`;
const formatNameAny = (p:any) => `${p.first} ${p.last}`;

interface Person {
  first: string;
  last: string;
}

const formatName = (p: Person) => `${p.first} ${p.last}`;
const formatNameAny = (p: any) => `${p.first} ${p.last}`;

然后你可以first在你的编辑器中选择“Rename Symbol”，把它改成firstName（见图1-5和1-6）。

then you can select first in your editor, choose “Rename Symbol,” and change it to firstName (see Figures 1-5 and 1-6).

图 1-5。在 vscode 中重命名符号。

图 1-6。选择新名称。TypeScript 语言服务确保项目中符号的所有使用也被重命名。

这会更改formatName功能但不会更改any版本：

This changes the formatName function but not the any version:

interface Person {
  firstName：：：：string;
  last_ string;
}
const formatName = (p_ Person) => `${p.firstName} ${p.last}`;
const formatNameAny = (p_any) => `${p.first} ${p.last}`;

interface Person {
  firstName: string;
  last: string;
}
const formatName = (p: Person) => `${p.firstName} ${p.last}`;
const formatNameAny = (p: any) => `${p.first} ${p.last}`;

TypeScript 的座右铭是“可扩展的 JavaScript”。“规模”的一个关键部分是语言服务，它是 TypeScript 体验的核心部分（请参阅第 6 项）。失去它们将导致生产力下降，不仅对您如此，对使用您的代码的其他人也是如此。

TypeScript’s motto is “JavaScript that scales.” A key part of “scales” is the language services, which are a core part of the TypeScript experience (see Item 6). Losing them will lead to a loss in productivity, not just for you but for everyone else working with your code.

interface ComponentProps {
  onSelectItem: (item:any) => void;
}

interface ComponentProps {
  onSelectItem: (item: any) => void;
}

function renderSelector(props:ComponentProps) { /* ... */ }

let selectedId: number = 0;
function handleSelectItem(item:any) {
  selectedId = item.id;
}

renderSelector({onSelectItem:handleSelectItem});

function renderSelector(props: ComponentProps) { /* ... */ }

let selectedId: number = 0;
function handleSelectItem(item: any) {
  selectedId = item.id;
}

renderSelector({onSelectItem: handleSelectItem});

interface ComponentProps {
  onSelectItem: (id:number) => void;
}

interface ComponentProps {
  onSelectItem: (id: number) => void;
}